From mbaiju at zeomega.com Fri Feb 5 21:40:43 2010 From: mbaiju at zeomega.com (Baiju M) Date: Fri Feb 5 17:10:48 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux Message-ID: Hi, Is there any document which explains setting up mxODBCZopeDA with iODBC in Linux. I am looking for something which use Oracle instantclient. Regards, Baiju M From mal at egenix.com Fri Feb 5 17:24:11 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 5 17:24:15 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux In-Reply-To: References: Message-ID: <4B6C462B.9080700@egenix.com> Baiju M wrote: > Hi, > Is there any document which explains setting up mxODBCZopeDA > with iODBC in Linux. I am looking for something which use > Oracle instantclient. Setting up iODBC is just a straight-forward as setting up unixODBC. See e.g. this how-to: http://www.iodbc.org/dataspace/iodbc/wiki/iODBC/IODBCPythonHOWTO These are few links to the mxODBC Zope DA documentation: http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329296 http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329299 The mxODBC Zope DA allows you to select which ODBC manager to use on Unix - depending on which are installed. Since both managers provide more or less the same interface, it's usually best to just install one of them and select the "Platform Default" choice. This results in mxODBC Zope DA picking up the ODBC that's installed on the system and is more portable in case you plan to move the connection object to a different installation: http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329309 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From charlie at egenix.com Fri Feb 5 19:33:04 2010 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 5 19:33:11 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux In-Reply-To: References: Message-ID: Am 05.02.2010, 17:10 Uhr, schrieb Baiju M : > I am looking for something which use > Oracle instantclient. Hiya Baiju, given a number of errors in the past we would warn against using the Oracle Instant Client and ODBC. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Sat Feb 6 12:47:56 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 6 12:48:01 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux In-Reply-To: References: Message-ID: <4B6D56EC.6020907@egenix.com> Just to clarify: The situation with the Oracle Instant Client has gotten a lot better recently and is now updated frequently enough to base serious applications on. Charlie was referring to the early days when Oracle recommended to use the ODBC driver that comes with the Oracle server instead of the one that shipped with Oracle Instant Client. The number of reported problems with the Oracle ODBC driver has dropped to zero lately. Charlie Clark wrote: > Am 05.02.2010, 17:10 Uhr, schrieb Baiju M : > >> I am looking for something which use >> Oracle instantclient. > > Hiya Baiju, > > given a number of errors in the past we would warn against using the > Oracle Instant Client and ODBC. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 06 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mbaiju at zeomega.com Sat Feb 6 17:52:49 2010 From: mbaiju at zeomega.com (Baiju M) Date: Sat Feb 6 13:22:55 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux In-Reply-To: <4B6D56EC.6020907@egenix.com> References: <4B6D56EC.6020907@egenix.com> Message-ID: Thanks Marc & Charlie for your valuable comments. We will these options. P.S: We are eagerly waiting for final release of mxODBCZopeDA for Zope 2.12 with Python 2.6 in 64 bit Linux. Regards, Baiju M From mal at egenix.com Tue Feb 16 12:58:12 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 16 12:58:19 2010 Subject: [egenix-users] Error from mxODBCZopeDA for Zope 2.12 with Python 2.6 on x86_64 In-Reply-To: References: <4B2B524A.2080509@egenix.com> Message-ID: <4B7A8854.1060903@egenix.com> Baiju M wrote: > On Fri, Dec 18, 2009 at 3:28 PM, M.-A. Lemburg wrote: >> Baiju M wrote: >>> Hi, >>> I am using beta version of mxODBCZopeDA for Zope 2.12 with Python >>> 2.6 on x86_64. >>> File: egenix-mxodbc-zopeda-1.0.10.linux-x86_64-py2.4_ucs4.zip >>> >>> When I am trying to make a query, it shows "ODBC driver sent negative >>> string size" error. >>> This is the output from Zope's debug prompt: >>> >>>>>> app.db._v_database_connection.query("select * from tbl_name") >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "Products/mxODBCZopeDA/ZopeDA.py", line 1534, in query >>> File "Products/mxODBCZopeDA/ZopeDA.py", line 1409, in run_cursor_callback >>> mx.ODBC.Error.InterfaceError: ODBC driver sent negative string size >>> >>> I am using "unixODBC 2.2.15pre". With unixODBC 2.2.14 also this error >>> is raised. >>> But in 2.2.14 I cann't even get any result from "isql" command line prompt. >>> >>> I am connecting to Oracle using instant_client 10.2.0.4 for x86_64 >>> >>> Few other details: >>> >>> $ uname -a >>> Linux xxxxxxxxxx 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 >>> x86_64 x86_64 x86_64 GNU/Linux >>> $ cat /etc/redhat-release >>> CentOS release 5.3 (Final) >>> >>> Please let me know if any more details required >> >> This appears to be a bug in unixODBC 2.2.14. We've had similar >> reports for the MySQL ODBC driver used in combination with >> unixODBC 2.2.14. >> >> Please try unixODBC 2.2.12 and see if the problem goes away. > > I forgot to mention, I have tried 2.2.12 also. It was showing the same error. > > FYI, In 2.2.12 & 2.2.14 we are getting this error from "isql": > > [ISQL]ERROR: Could not SQLAllocStmt > > I can see this error mentioned in Oracle forum: > http://forums.oracle.com/forums/thread.jspa?threadID=340030&tstart=0 We have now spoken to EasySoft who maintain unixODBC: they apparently switched two important variable types between the releases 2.2.12 and 2.2.13 of the unixODBC manager. In 2.2.12, unixODBC defaults to using 32-bit values for the SQLLEN/SQLULEN types. In 2.2.14, it defaults to 64-bit values. Unfortunately, they left the library version name at the same libodbc.so.1.0.0, so the linker won't hint you to a possible problem with the API change. Our products are built against unixODBC 2.2.12 and use its default settings. As a result they use 32-bit values for all SQLLEN/SQLULEN parameters. When used against a 2.2.14+ unixODBC manager library, the linker won't complain (it sees the same version on the file), but all calls will end up creating a garbled stack. Now, to make things even more interesting, the Oracle driver for 64-bit Linux uses 64-bit SQLLEN values as well, so you can't use it with unixODBC 2.2.12, but you should be able to use it with 2.2.14 or a later version. Note that iODBC, the other ODBC manager for Unix, still uses the 32-bit defaults. We'll have to find a way to make all this just magically work in some way. 64-bit ODBC is a real mess and the fact that MS changed SQLLEN from long to long long on Win64 late in the spec process and after Unix 64-bit platforms had already adopted the 32-bit interpretation didn't really help either. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Thu Feb 25 00:15:58 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 25 00:16:03 2010 Subject: [egenix-users] mxODBCZopeDA with iODBC in Linux In-Reply-To: <4B6C462B.9080700@egenix.com> References: <4B6C462B.9080700@egenix.com> Message-ID: <4B85B32E.4060203@egenix.com> M.-A. Lemburg wrote: > Baiju M wrote: >> Hi, >> Is there any document which explains setting up mxODBCZopeDA >> with iODBC in Linux. I am looking for something which use >> Oracle instantclient. > > Setting up iODBC is just a straight-forward as setting up > unixODBC. See e.g. this how-to: > > http://www.iodbc.org/dataspace/iodbc/wiki/iODBC/IODBCPythonHOWTO > > These are few links to the mxODBC Zope DA documentation: > > http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329296 > http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329299 > > The mxODBC Zope DA allows you to select which ODBC manager > to use on Unix - depending on which are installed. > > Since both managers provide more or less the same interface, > it's usually best to just install one of them and select > the "Platform Default" choice. > > This results in mxODBC Zope DA > picking up the ODBC that's installed on the system and is more > portable in case you plan to move the connection object to > a different installation: > > http://www.egenix.com/products/zope/mxODBCZopeDA/doc/#_Toc117329309 BTW: There's one catch with the iODBC manager that you run into: It defaults to using the 4-byte wchar_t type for Unicode on Linux. Since many ODBC drivers follow the MS ODBC standard which uses a 2-byte wchar_t type for Unicode, iODBC will cause problems when used with these drivers and Unicode. It does not appear to be easily possible to compile iODBC to use a 2-byte Unicode type, short of editing sqltypes.h to force use a 2-byte type. unixODBC uses the 2-byte Unicode type on Linux per default, so you don't run into these issues, but you have other issues related to a few length types being 4 bytes on older versions and 8 bytes in more recent ones on 64-bit Linux - which iODBC doesn't have. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mbaiju at zeomega.com Thu Feb 25 12:25:36 2010 From: mbaiju at zeomega.com (Baiju M) Date: Thu Feb 25 07:55:41 2010 Subject: [egenix-users] UCS4 vs UCS2 in Linux Message-ID: Hi, Our application only require support latin-1 character. Do you reccomend to use UCS2 version of mxODBCZopeDA for Linux ? If we use UCS4, does it going to use more memory ? Regards, Baiju M From fernando at cmartins.nl Thu Feb 25 09:56:38 2010 From: fernando at cmartins.nl (Fernando Martins) Date: Thu Feb 25 09:56:40 2010 Subject: [egenix-users] db2 related question Message-ID: <4B863B46.7010807@cmartins.nl> Hi, I have a zope Intranet website with a MySQL backend and I'm tasked to migrate from MySQL to DB2 Express (the official dbms). Zope will also have to go away sooner or later, but I the first step is the DBMS. The problem I'm facing with, is that DB2 "prefers" to work with tables and field names in capitals, whereas the db in MySQL mixes case. That means that I cannot migrate transparently, at first sight. I could change the SQL statements to use quotes and force the mixed case, but it's still quite a bit of work. I could migrate to a capital case system and change the zope front-end, but that's even more work. Now, I also have a MS-Access frontend and as a matter of fact the ODBC layer (or MS Access) takes care of transparently converting from mixed to capital case and vice-versa. I was wondering if the mxODBC interface for DB2 can actually do the same? Regards, Fernando From mal at egenix.com Thu Feb 25 10:10:40 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 25 10:10:44 2010 Subject: [egenix-users] UCS4 vs UCS2 in Linux In-Reply-To: References: Message-ID: <4B863E90.7050202@egenix.com> Baiju M wrote: > Hi, > Our application only require support latin-1 character. > Do you reccomend to use UCS2 version of mxODBCZopeDA for Linux ? > If we use UCS4, does it going to use more memory ? The Zope DA 1.0 defaults to using 8-bit strings for text interaction with the database. For 2.0, we are going to add an option to use Unicode or a mixed setup as well. UCS2 vs. UCS4 only affects Unicode objects, so if you don't use Unicode, there's not a lot of difference between the two builds. If you do intend to go with Unicode in the future, the question of memory consumption and conversion performance arises. Both are only relevant if you store lots of text in Unicode. UCS2 uses 2 bytes to store a single character, UCS4 4 bytes. Most ODBC drivers on Linux use 2 byte characters for Unicode, so if you use UCS4, the Zope DA would have to convert between Python's UCS4 and the driver's UCS2. Note that Python's default is UCS2 (on all platforms), because it was found to be a good compromise between memory consumption and flexibility. The glibc on Linux chose to go with UCS4, which is why many Linux distributions use UCS4 as default Python build. The BSDs are yet undecided: FreeBSD now ships with UCS4 as default build. Mac OS X uses UCS2. UCS4 makes things easier for Asian scripts, since these sometimes use characters outside the UCS2 range. In such a case, UCS2 has to use 2 storage units to store a single characters (the so-called surrogates). UCS4 avoids this, since a single storage unit can handle all Unicode characters. However, it's not the all-inclusive "doesn't break when sliced" solution that some propagate it as. Just like UCS2, UCS4 has the same problems with slicing when it comes to combining characters, e.g. an "e" combined with a "?" to form "?". Hope that provides some guidelines. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mal at egenix.com Thu Feb 25 10:52:50 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 25 10:52:55 2010 Subject: [egenix-users] db2 related question In-Reply-To: <4B863B46.7010807@cmartins.nl> References: <4B863B46.7010807@cmartins.nl> Message-ID: <4B864872.9090107@egenix.com> Fernando Martins wrote: > Hi, > > I have a zope Intranet website with a MySQL backend and I'm tasked to > migrate from MySQL to DB2 Express (the official dbms). Zope will also > have to go away sooner or later, but I the first step is the DBMS. > > The problem I'm facing with, is that DB2 "prefers" to work with tables > and field names in capitals, whereas the db in MySQL mixes case. That > means that I cannot migrate transparently, at first sight. I could > change the SQL statements to use quotes and force the mixed case, but > it's still quite a bit of work. I could migrate to a capital case system > and change the zope front-end, but that's even more work. > > Now, I also have a MS-Access frontend and as a matter of fact the ODBC > layer (or MS Access) takes care of transparently converting from mixed > to capital case and vice-versa. > > I was wondering if the mxODBC interface for DB2 can actually do the same? mxODBC itself does not parse the SQL you pass to it. The ODBC driver and/or database do such parsing and thus it's possible that the ODBC driver can implement such conversion between mixed case and all upper case identifiers. However, I wonder why that's a problem in your case: DB2 adheres to the SQL standard which mandates to be case insensitive regarding identifiers, unless those identifiers are quoted. I'm not sure whether it's in the standard as well, but most enterprise databases use all capital letter for storing identifiers (and some even for things like user names and passwords). So you have the following situation: MyTable, MYTABLE and myTable are all the same table. The database uses MYTABLE to reference the table internally. "MyTable", "MYTABLE" and "myTable" are three different tables. Unless you have a situation where case really matters, e.g. two fields "ID" and "id", you should be able to just continue using mixed case identifiers in your Zope application (without quoting them) and have the database match these case-insensitive to what it stores internally. Here's an article about case sensitivity of DB2: http://www.ibm.com/developerworks/data/library/techarticle/0203adamache/0203adamache.html Also note that the DB2 ODBC provides quite a few options to make porting existing applications easier: http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.cli.doc/doc/r0007964.htm You can use those with mxODBC or our mxODBC Zope DA. This is the official MySQL to DB2 conversion guide: http://www.redbooks.ibm.com/abstracts/sg247093.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From fernando at cmartins.nl Thu Feb 25 10:49:26 2010 From: fernando at cmartins.nl (Fernando) Date: Thu Feb 25 11:49:30 2010 Subject: [egenix-users] db2 related question In-Reply-To: <4B864872.9090107@egenix.com> References: <4B863B46.7010807@cmartins.nl> <4B864872.9090107@egenix.com> Message-ID: <20100225104926.3A257304A02F@bmail00.one.com> On Feb 25, 2010 09:52 "M.-A. Lemburg" wrote: > mxODBC itself does not parse the SQL you pass to it. The ODBC driver > and/or database do such parsing and thus it's possible that the ODBC > driver can implement such conversion between mixed case and all upper > case identifiers. > > However, I wonder why that's a problem in your case: > > DB2 adheres to the SQL standard which mandates to be case insensitive > regarding identifiers, unless those identifiers are quoted. > > > Thanks for your detailed answer. DB2-ExpressC doesn't seem to be compliant, though. I have this test table in DB2: lktBuildings(BUILDINGID, BuildCode) Using MS Access SQL PassThrough, SQL statements are tunnelled through ODBC without SQL parsing. If I send SELECT "lktBuildings".BUILDINGID, "lktBuildings"."BuildCode" FROM "lktBuildings"; it works fine, but if I send SELECT "lktBuildings".BUILDINGID, "lktBuildings".BuildCode FROM "lktBuildings"; (no quotes around BuildCode), I get the error [IBM][CLI Driver][DB2/LINUXX8664] SQL0206N "lktBuildings.BUILDCODE" is not valid in the context where it is used. SQLSTATE=42703 (#-206) And the documentation states that "For a SELECT or DELETE statement, the specified column is not a column of any of the tables or views identified in a FROM clause in the statement." I'll check the links you provided, thanks, Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20100225/9337008a/attachment.htm From mal at egenix.com Thu Feb 25 12:25:08 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 25 12:25:13 2010 Subject: [egenix-users] db2 related question In-Reply-To: <20100225104926.3A257304A02F@bmail00.one.com> References: <4B863B46.7010807@cmartins.nl> <4B864872.9090107@egenix.com> <20100225104926.3A257304A02F@bmail00.one.com> Message-ID: <4B865E14.9050400@egenix.com> Fernando wrote: > On Feb 25, 2010 09:52 "M.-A. Lemburg" wrote: > >> mxODBC itself does not parse the SQL you pass to it. The ODBC driver >> and/or database do such parsing and thus it's possible that the ODBC >> driver can implement such conversion between mixed case and all upper >> case identifiers. >> >> However, I wonder why that's a problem in your case: >> >> DB2 adheres to the SQL standard which mandates to be case insensitive >> regarding identifiers, unless those identifiers are quoted. >> >> >> > Thanks for your detailed answer. DB2-ExpressC doesn't seem to be > compliant, though. > > I have this test table in DB2: lktBuildings(BUILDINGID, BuildCode) > > Using MS Access SQL PassThrough, SQL statements are tunnelled through > ODBC without SQL parsing. If I send > > SELECT "lktBuildings".BUILDINGID, "lktBuildings"."BuildCode" > FROM "lktBuildings"; > > it works fine, but if I send > > SELECT "lktBuildings".BUILDINGID, "lktBuildings".BuildCode > FROM "lktBuildings"; > > (no quotes around BuildCode), I get the error > > [IBM][CLI Driver][DB2/LINUXX8664] SQL0206N "lktBuildings.BUILDCODE" is > not valid in the context where it is used. SQLSTATE=42703 (#-206) For the above to work, you have to create the tables, views, etc. without using quoted identifiers. In the above case, you seem to have a field created as "BuildCode" (with quotes). If you create this as BuildCode (without the quotes), the first example will fail, but the second will work. My suggestion is to not use quoted identifiers at all in your application or the schema definition. That way you get a more portable application. You can still use CamelCase in the definitions, queries, etc. to improve readability, but at the database kernel level, this is normally not needed. If you still need those CamelCase columns or table names for some reason, I'd suggest to use "SELECT CamelCase as "CamelCase", ..." and/or views to rebind the column names using quoted versions. > And the documentation states that "For a SELECT or DELETE statement, the > specified column is not a column of any of the tables or views > identified in a FROM clause in the statement." > > I'll check the links you provided, thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From fernando at cmartins.nl Thu Feb 25 14:49:47 2010 From: fernando at cmartins.nl (Fernando) Date: Thu Feb 25 15:49:51 2010 Subject: [egenix-users] db2 related question In-Reply-To: <4B865E14.9050400@egenix.com> References: <20100225104926.3A257304A02F@bmail00.one.com> <4B865E14.9050400@egenix.com> Message-ID: <20100225144947.8FCFF304A02F@bmail00.one.com> On Feb 25, 2010 11:25 "M.-A. Lemburg" wrote: > > For the above to work, you have to create the tables, views, > etc. without using quoted identifiers. > > > All right! Just tested and it works! How objects were created makes all the difference on how they are treated afterwards. Many thanks! Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20100225/dba86449/attachment.htm From fernando at cmartins.nl Thu Feb 25 14:55:17 2010 From: fernando at cmartins.nl (Fernando) Date: Thu Feb 25 15:55:20 2010 Subject: [egenix-users] db2 related question In-Reply-To: <20100225144947.8FCFF304A02F@bmail00.one.com> References: <4B865E14.9050400@egenix.com> <20100225144947.8FCFF304A02F@bmail00.one.com> Message-ID: <20100225145517.16E52377E1DA6@bmail02.one.com> Actually I spoke too soon. The main problem is in the existing Python references in the Zope frontend. DB2 returns everything in capitals and something in python like record["BuildCode"] will not work... Regards, Fernando On Feb 25, 2010 14:49 "Fernando" wrote: > On Feb 25, 2010 11:25 "M.-A. Lemburg" wrote: > > > > > For the above to work, you have to create the tables, views, > > etc. without using quoted identifiers. > > > > > > > All right! Just tested and it works! How objects were created makes > all the difference on how they are treated afterwards. > > Many thanks! > > Fernando > -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20100225/e43de6fc/attachment.htm From mal at egenix.com Thu Feb 25 17:35:55 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 25 17:35:58 2010 Subject: [egenix-users] db2 related question In-Reply-To: <20100225145517.16E52377E1DA6@bmail02.one.com> References: <4B865E14.9050400@egenix.com> <20100225144947.8FCFF304A02F@bmail00.one.com> <20100225145517.16E52377E1DA6@bmail02.one.com> Message-ID: <4B86A6EB.4080107@egenix.com> Fernando wrote: > Actually I spoke too soon. The main problem is in the existing Python > references in the Zope frontend. DB2 returns everything in capitals and > something in python like record["BuildCode"] will not work... True. You'd have to use all lower or all upper case letters for the dictionary access - or use positional access to avoid any such issues. Unfortunately, the Zope Results and Record classes (see Shared/DC/ZRDB/Results.py and the Zope Record package) don't support case-insensitive field access. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ > Regards, > Fernando > > On Feb 25, 2010 14:49 "Fernando" wrote: > >> On Feb 25, 2010 11:25 "M.-A. Lemburg" wrote: >> >>> >>> For the above to work, you have to create the tables, views, >>> etc. without using quoted identifiers. >>> >>> >>> >> All right! Just tested and it works! How objects were created makes >> all the difference on how they are treated afterwards. >> >> Many thanks! >> >> Fernando >>