From alexandre.fayolle at logilab.fr Tue Apr 13 12:44:27 2010 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Tue Apr 13 11:44:32 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index Message-ID: <201004131144.27619.alexandre.fayolle@logilab.fr> Hi, I have an application which currently runs with pyodbc to connect to an SQLServer 2005 database. It works fine but very slowly (50x more slowly than the same app running against PostrgreSQL via psycopg2), and this might kill our so I'm investigating if mx.ODBC could improve the perfs in which case I'll be happy to to buy a licence. I've solved a couple of easy problems concerning the SQL <-> Python mapping differences between pyodbc and mx.ODBC, but I have an issue with the following query: SELECT ? FROM owned_by_relation WHERE eid_from=? AND eid_to=? which is executed with parameters (2031, 2031, 5) This query runs fine with pyodbc (and psycopg, mysqldb, sqlite...) but with mx.ODBC it generates InterfaceError: ('07009', 0, '[Microsoft][SQL Server Native Client 10.0]Invalid Descriptor Index', 7513) The problem is with the first ? (in the SELECT part of the request). My options in tweaking the SQL are somewhat limited, because the SQL is generated by some kind of ORM and we want to keep the rest of the code base as backend-agnostic as possible. I've seen http://www.egenix.com/mailman-archives/egenix-users/2009- May/114571.html suggesting to use executedirect, but when I tried that, the program crashed in another place because of date/time issues: mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL Server Native Client 10.0]Datetime field overflow. Fractional second precision exceeds the scale specified in the parameter binding.', 7748) At this point, I'm a bit stuck and would appreciate any help platform information: * windows server 2003 * python 2.5.4 * mxODBC 3.04 * mx Base 3.1.3 * SQL Server 2005 * ODBC Driver : SQL Server Native Client 10.0 Thanks in advance -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From mal at egenix.com Tue Apr 13 13:03:27 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Apr 13 12:02:56 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004131144.27619.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> Message-ID: <4BC4416F.1040105@egenix.com> Hello Alexandre, Alexandre Fayolle wrote: > Hi, > > I have an application which currently runs with pyodbc to connect to an > SQLServer 2005 database. It works fine but very slowly (50x more slowly than > the same app running against PostrgreSQL via psycopg2), and this might kill > our so I'm investigating if mx.ODBC could improve the perfs in which case I'll > be happy to to buy a licence. > > I've solved a couple of easy problems concerning the SQL <-> Python mapping > differences between pyodbc and mx.ODBC, but I have an issue with the following > query: > > SELECT ? FROM owned_by_relation > WHERE eid_from=? AND eid_to=? > > which is executed with parameters (2031, 2031, 5) > > This query runs fine with pyodbc (and psycopg, mysqldb, sqlite...) but with > mx.ODBC it generates > > InterfaceError: ('07009', 0, '[Microsoft][SQL Server Native Client > 10.0]Invalid Descriptor Index', 7513) > > The problem is with the first ? (in the SELECT part of the request). Right. Parameter markers are not allowed in a SELECT list. Some more background on the subject, since we've been getting such questions a lot in recent months. http://msdn.microsoft.com/en-us/library/ms711808(VS.85).aspx """ Parameters are valid only in certain places in SQL statements. For example, they are not allowed in the select list (the list of columns to be returned by a SELECT statement), nor are they allowed as both operands of a binary operator such as the equal sign (=), because it would be impossible to determine the parameter type. Generally, parameters are valid only in Data Manipulation Language (DML) statements, and not in Data Definition Language (DDL) statements. For more information, see Parameter Markers in Appendix C: SQL Grammar. """ and http://msdn.microsoft.com/en-us/library/ms709310(VS.85).aspx """ Parameter Markers In accordance with the SQL-92 specification, an application cannot place parameter markers in the following locations. For a more comprehensive list, see the SQL-92 specification. * In a SELECT list * As both expressions in a comparison-predicate * As both operands of a binary operator * As both the first and second operands of a BETWEEN operation * As both the first and third operands of a BETWEEN operation * As both the expression and the first value of an IN operation * As the operand of a unary + or ? operation * As the argument of a set-function-reference """ SQL Server's ODBC driver unfortunately has a few other limitations as well. Here's a list of known situations where using parameter markers will always fail with SQL Server Native Client's ODBC driver and non-direct execution (ie. using prepare/execute and SQL type binding which relies on the ODBC API SQLDescribeParam): http://msdn.microsoft.com/en-us/library/ms130945.aspx """ * For any ODBC or Transact-SQL statement containing a parameter in a HAVING clause, or compared to the result of a SUM function. * For any ODBC or Transact-SQL statement depending on a subquery containing parameters. * For ODBC SQL statements containing parameter markers in both expressions of a comparison, like, or quantified predicate. * For any queries where one of the parameters is a parameter to a function. * When there are comments (/* */) in the Transact-SQL command. """ The reason you see errors with mxODBC and not with pyodbc is that mxODBC tries to use SQL type binding (the ODBC driver tells mxODBC what to send, avoiding temporary copies and conversions) if possible. pyodbc only supports Python type binding (the Python application defines what to send). Since SQL Server's ODBC driver supports SQL type binding, this is what mxODBC uses per default. cursor.executedirect() is a way to work around that default on a per-statement basis. It forces mxODBC to use Python type binding for that statement. > My options in tweaking the SQL are somewhat limited, because the SQL is > generated by some kind of ORM and we want to keep the rest of the code base as > backend-agnostic as possible. > > I've seen http://www.egenix.com/mailman-archives/egenix-users/2009- > May/114571.html suggesting to use executedirect, but when I tried that, the > program crashed in another place because of date/time issues: > > mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL Server Native Client > 10.0]Datetime field overflow. Fractional second precision exceeds the scale > specified in the parameter binding.', 7748) > > At this point, I'm a bit stuck and would appreciate any help How are you passing those date/time values to mxODBC ? As mxDateTime instances, strings or datetime module instances ? An ODBC trace log would help find out what the ODBC driver is asking for. > platform information: > > * windows server 2003 > * python 2.5.4 > * mxODBC 3.04 > * mx Base 3.1.3 > * SQL Server 2005 > * ODBC Driver : SQL Server Native Client 10.0 > > Thanks in advance > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 13 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 alexandre.fayolle at logilab.fr Thu Apr 15 18:14:02 2010 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Apr 15 17:14:08 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC4416F.1040105@egenix.com> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <4BC4416F.1040105@egenix.com> Message-ID: <201004151714.02171.alexandre.fayolle@logilab.fr> On Tuesday 13 April 2010 12:03:27 M.-A. Lemburg wrote: > Hello Alexandre, Hello Marc Andre, Thanks for your detailed answer. I was not aware of the SELECT list limitation on parameters. I shall investigate if we can twist the ORM around this to use the more efficient method (as what I'm after is speed). > > > > mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL Server Native > > Client 10.0]Datetime field overflow. Fractional second precision exceeds > > the scale specified in the parameter binding.', 7748) > > > > At this point, I'm a bit stuck and would appreciate any help > > How are you passing those date/time values to mxODBC ? As > mxDateTime instances, strings or datetime module instances ? > > An ODBC trace log would help find out what the ODBC driver > is asking for. Here's some additional information on this specific bug (the %(name)s quoting in the SQL is processed to use the ? style quoting): sql: 'UPDATE cw_CWUser SET cw_modification_date = %(cw_modification_date)s, cw_last_login_time = %(cw_last_login_time)s WHERE cw_eid = %(cw_eid)s' args: {'cw_eid': 5, 'cw_modification_date': datetime.datetime(2010, 4, 15, 16, 51, 25, 468000), 'cw_last_login_time': datetime.datetime(2010, 4, 15, 16, 51, 25, 453000)} Basically, the datetime values are obtained using datetime.datetime.now(). The column in the database use MS SQL datetime type. As for the ODBC trace log, I could not generate it. I have installed mxODBC and mxBase using MSI installers: do these include the debug support mentioned in the documentation, or do I have to use the ZIP prebuilt packages? Regards, -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From charlie at egenix.com Thu Apr 15 18:30:06 2010 From: charlie at egenix.com (Charlie Clark) Date: Thu Apr 15 17:30:11 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004151714.02171.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <4BC4416F.1040105@egenix.com> <201004151714.02171.alexandre.fayolle@logilab.fr> Message-ID: Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle : > Thanks for your detailed answer. I was not aware of the SELECT list > limitation > on parameters. I shall investigate if we can twist the ORM around this > to use > the more efficient method (as what I'm after is speed). One of the places where we hit the problem was in the SQLa 0.6 mxODBC dialect for MS SQL >> An ODBC trace log would help find out what the ODBC driver >> is asking for. > Here's some additional information on this specific bug (the %(name)s > quoting > in the SQL is processed to use the ? style quoting): > sql: 'UPDATE cw_CWUser SET cw_modification_date = > %(cw_modification_date)s, > cw_last_login_time = %(cw_last_login_time)s WHERE cw_eid = %(cw_eid)s' > args: {'cw_eid': 5, 'cw_modification_date': datetime.datetime(2010, 4, > 15, 16, > 51, 25, 468000), 'cw_last_login_time': datetime.datetime(2010, 4, 15, > 16, 51, > 25, 453000)} > Basically, the datetime values are obtained using > datetime.datetime.now(). The > column in the database use MS SQL datetime type. > As for the ODBC trace log, I could not generate it. I have installed > mxODBC and mxBase using MSI installers: do these include the debug > support mentioned in the documentation, or do I have to use the ZIP > prebuilt packages? This looks like an incorrect application of the parameters. You *use* ? for parameters in this case. You must use string formatting to generate your SQL statement for "SELECT ?, ? FROM table" from your first example because you are passing variables to a statement and not parameters to the database which has already prepared the statement. Anytime you need "now" in a statement, get the database to generate it or set the variable to timestamp to have it done automatically on change. There is a bug in the MS SQL driver with the use of parameters in JOINs and sub-selects but that is not the case here. The ODBC trace log is produced by the ODBC driver not by mxODBC. 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 alexandre.fayolle at logilab.fr Thu Apr 15 18:55:13 2010 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Apr 15 17:55:17 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151714.02171.alexandre.fayolle@logilab.fr> Message-ID: <201004151755.13360.alexandre.fayolle@logilab.fr> Hello Charlie, Thanks for you answer. On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: > Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> > This looks like an incorrect application of the parameters. You *use* ? > for parameters in this case. You must use string formatting to generate > your SQL statement for "SELECT ?, ? FROM table" from your first example > because you are passing variables to a statement and not parameters to the > database which has already prepared the statement. Let me rephrase this. I was lazy, the call generating the exception was: datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL Server Native Client 10.0]Datetime field overflow. Fractional second precision exceeds the scale specified in the parameter binding.', 7748) > The ODBC trace log is produced by the ODBC driver not by mxODBC. I was thinking of the mxODBC.log file mentionned in ?4.7 of the mxODBC documentation. Is it possible to enable ODBC driver tracing when you don't go through the ODBC Data Source manager to connect to the database? -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From mal at egenix.com Thu Apr 15 20:03:02 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Apr 15 19:02:20 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004151755.13360.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151714.02171.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> Message-ID: <4BC746C6.5000004@egenix.com> Alexandre Fayolle wrote: > Hello Charlie, > > Thanks for you answer. > > On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: >> Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> > > >> This looks like an incorrect application of the parameters. You *use* ? >> for parameters in this case. You must use string formatting to generate >> your SQL statement for "SELECT ?, ? FROM table" from your first example >> because you are passing variables to a statement and not parameters to the >> database which has already prepared the statement. > > Let me rephrase this. I was lazy, the call generating the exception was: > > datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) > datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) > cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, > cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) > > The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL > Server Native Client 10.0]Datetime field overflow. Fractional second precision > exceeds the scale specified in the parameter binding.', 7748) This explains why you are seeing the error: Python datetime instances use more than just 2 digits precision in their seconds string representation, i.e. more than what SQL Server expects when requesting timestamps as strings. However, I wonder why SQL Server requests this data as string data, since it's well possible to use a native timestamp ODBC data structure for this, which also assures that full precision is maintained and no conversion takes place. Could you try the above with cursor.execute() and see whether you still get the same error ? >> The ODBC trace log is produced by the ODBC driver not by mxODBC. > > I was thinking of the mxODBC.log file mentionned in ?4.7 of the mxODBC > documentation. Is it possible to enable ODBC driver tracing when you don't go > through the ODBC Data Source manager to connect to the database? That depends on the driver you are using. For the mxODBC.log to be generated you need a special debug build which we can provide if needed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 15 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 Jim.Vickroy at noaa.gov Thu Apr 15 12:36:49 2010 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Apr 15 19:36:55 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC746C6.5000004@egenix.com> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151714.02171.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> <4BC746C6.5000004@egenix.com> Message-ID: <4BC74EB1.103@noaa.gov> M.-A. Lemburg wrote: > Alexandre Fayolle wrote: > >> Hello Charlie, >> >> Thanks for you answer. >> >> On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: >> >>> Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> >>> >> >>> This looks like an incorrect application of the parameters. You *use* ? >>> for parameters in this case. You must use string formatting to generate >>> your SQL statement for "SELECT ?, ? FROM table" from your first example >>> because you are passing variables to a statement and not parameters to the >>> database which has already prepared the statement. >>> >> Let me rephrase this. I was lazy, the call generating the exception was: >> >> datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) >> datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) >> cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, >> cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) >> >> The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL >> Server Native Client 10.0]Datetime field overflow. Fractional second precision >> exceeds the scale specified in the parameter binding.', 7748) >> > > This explains why you are seeing the error: Python datetime > instances use more than just 2 digits precision in their > seconds string representation, i.e. more than what SQL Server > expects when requesting timestamps as strings. > > However, I wonder why SQL Server requests this data as string > data, since it's well possible to use a native > timestamp ODBC data structure for this, which also assures > that full precision is maintained and no conversion takes place. > Could you try the above with cursor.execute() and see whether > you still get the same error ? > > >>> The ODBC trace log is produced by the ODBC driver not by mxODBC. >>> >> I was thinking of the mxODBC.log file mentionned in ?4.7 of the mxODBC >> documentation. Is it possible to enable ODBC driver tracing when you don't go >> through the ODBC Data Source manager to connect to the database? >> > > That depends on the driver you are using. > > For the mxODBC.log to be generated you need a special debug build > which we can provide if needed. > > FWIW, I have applications that perform SQL Server (2003 and 2008) inserts using datetime.datetime instances as a matter of course (1-minute cadence 24x7). -- jv > -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20100415/1cea05ac/attachment.htm From alexandre.fayolle at logilab.fr Thu Apr 15 20:56:56 2010 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Thu Apr 15 19:57:05 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC4416F.1040105@egenix.com> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <4BC4416F.1040105@egenix.com> Message-ID: <201004151956.56149.alexandre.fayolle@logilab.fr> On Tuesday 13 April 2010 12:03:27 M.-A. Lemburg wrote: > """ > * For any ODBC or Transact-SQL statement containing a parameter in a HAVING > clause, or compared to the result of a SUM function. > * For any ODBC or Transact-SQL statement depending on a subquery containing > parameters. So this would be why I get a failure for SELECT DISTINCT rel_require_permission0.eid_to FROM require_permission_relation AS rel_require_permission0 WHERE rel_require_permission0.eid_from=? AND NOT EXISTS(SELECT 1 FROM require_permission_relation AS rel_require_permission1 WHERE rel_require_permission1.eid_from=? AND rel_require_permission0.eid_to=rel_require_permission1.eid_to) correct? > Since SQL Server's ODBC driver supports SQL type binding, this > is what mxODBC uses per default. > > cursor.executedirect() is a way to work around that default on > a per-statement basis. It forces mxODBC to use Python type binding > for that statement. But if I read the documentation correctly, doing this won't prepare the statement, which will worsen the perfs if the statement is reused a lot. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From charlie at egenix.com Thu Apr 15 21:42:55 2010 From: charlie at egenix.com (Charlie Clark) Date: Thu Apr 15 20:43:01 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004151956.56149.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <4BC4416F.1040105@egenix.com> <201004151956.56149.alexandre.fayolle@logilab.fr> Message-ID: Am 15.04.2010, 19:56 Uhr, schrieb Alexandre Fayolle : > So this would be why I get a failure for > SELECT DISTINCT rel_require_permission0.eid_to > FROM require_permission_relation AS rel_require_permission0 > WHERE rel_require_permission0.eid_from=? > AND NOT EXISTS (SELECT 1 FROM require_permission_relation AS > rel_require_permission1 WHERE rel_require_permission1.eid_from=? > AND rel_require_permission0.eid_to=rel_require_permission1.eid_to) > correct? Yes, the driver chokes on the parameter in the sub-select. >> Since SQL Server's ODBC driver supports SQL type binding, this >> is what mxODBC uses per default. >> >> cursor.executedirect() is a way to work around that default on >> a per-statement basis. It forces mxODBC to use Python type binding >> for that statement. > But if I read the documentation correctly, doing this won't prepare the > statement, which will worsen the perfs if the statement is reused a lot. In theory this would be the case. In practice it *might* not be so dramatic but you should definitely profile it. We've seen some discussion even favouring this approach: http://msdn.microsoft.com/en-us/library/ms175528%28SQL.90%29.aspx "In SQL Server 2005, the prepare/execute model has no significant performance advantage over direct execution, because of the way SQL Server 2005 reuses execution plans. SQL Server 2005 has efficient algorithms for matching current SQL statements with execution plans that are generated for prior executions of the same SQL statement. If an application executes a SQL statement with parameter markers multiple times, SQL Server 2005 will reuse the execution plan from the first execution for the second and subsequent executions (unless the plan ages from the procedure cache). The prepare/execute model still has these benefits: - Finding an execution plan by an identifying handle is more efficient than the algorithms used to match an SQL statement to existing execution plans. - The application can control when the execution plan is created and when it is reused. - The prepare/execute model is portable to other databases, including earlier versions of SQL Server." Hopefully enough bug reports will encourage Microsoft to fix it. 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 Thu Apr 15 21:49:04 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Apr 15 20:48:22 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC74EB1.103@noaa.gov> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151714.02171.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> <4BC746C6.5000004@egenix.com> <4BC74EB1.103@noaa.gov> Message-ID: <4BC75FA0.9090200@egenix.com> Jim Vickroy wrote: > M.-A. Lemburg wrote: >> Alexandre Fayolle wrote: >> >>> Hello Charlie, >>> Thanks for you answer. >>> On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: >>> >>>> Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> >>> >>>> This looks like an incorrect application of the parameters. You *use* ? >>>> for parameters in this case. You must use string formatting to generate >>>> your SQL statement for "SELECT ?, ? FROM table" from your first example >>>> because you are passing variables to a statement and not parameters >>>> to the >>>> database which has already prepared the statement. >>> Let me rephrase this. I was lazy, the call generating the exception was: >>> >>> datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) >>> datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) >>> cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, >>> cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) >>> >>> The exception is mx.ODBC.Error.DataError: ('22008', 0, >>> '[Microsoft][SQL Server Native Client 10.0]Datetime field overflow. >>> Fractional second precision exceeds the scale specified in the >>> parameter binding.', 7748) >>> >> >> This explains why you are seeing the error: Python datetime >> instances use more than just 2 digits precision in their >> seconds string representation, i.e. more than what SQL Server >> expects when requesting timestamps as strings. >> >> However, I wonder why SQL Server requests this data as string >> data, since it's well possible to use a native >> timestamp ODBC data structure for this, which also assures >> that full precision is maintained and no conversion takes place. >> > Could you try the above with cursor.execute() and see whether >> you still get the same error ? >> >> >>>> The ODBC trace log is produced by the ODBC driver not by mxODBC. >>>> >>> I was thinking of the mxODBC.log file mentionned in ?4.7 of the >>> mxODBC documentation. Is it possible to enable ODBC driver tracing >>> when you don't go through the ODBC Data Source manager to connect to >>> the database? >> >> That depends on the driver you are using. >> >> For the mxODBC.log to be generated you need a special debug build >> which we can provide if needed. >> >> > > > FWIW, I have applications that perform SQL Server (2003 and 2008) > inserts using datetime.datetime instances as a matter of course > (1-minute cadence 24x7). -- jv There's a little known fact about Python datetime instances: they omit the fractions part if the microsecond value is 0. >>> import datetime >>> str(datetime.datetime(2010,4,15,0,0,0,1)) '2010-04-15 00:00:00.000001' Precision is 6 if you provide microseconds. >>> str(datetime.datetime(2010,4,15,0,0,0,0)) '2010-04-15 00:00:00' Precision is 0 if the microsecond value is 0. >>> str(datetime.datetime.now()) '2010-04-15 19:53:04.532707' With .now() on Linux and Windows (and probably other platforms as well) it's likely that you'll get a precision 6 string value. In any case, we'll try to reproduce the problem with our test servers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 15 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 Apr 15 21:57:02 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Apr 15 20:56:19 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004151956.56149.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <4BC4416F.1040105@egenix.com> <201004151956.56149.alexandre.fayolle@logilab.fr> Message-ID: <4BC7617E.8080405@egenix.com> Alexandre Fayolle wrote: > On Tuesday 13 April 2010 12:03:27 M.-A. Lemburg wrote: >> """ >> * For any ODBC or Transact-SQL statement containing a parameter in a HAVING >> clause, or compared to the result of a SUM function. >> * For any ODBC or Transact-SQL statement depending on a subquery containing >> parameters. > > So this would be why I get a failure for > > SELECT DISTINCT rel_require_permission0.eid_to > FROM require_permission_relation AS rel_require_permission0 > WHERE rel_require_permission0.eid_from=? > AND NOT EXISTS(SELECT 1 FROM require_permission_relation AS > rel_require_permission1 WHERE rel_require_permission1.eid_from=? > AND rel_require_permission0.eid_to=rel_require_permission1.eid_to) > > correct? Yes. You have a sub-select in there. We've also had reports of the same problems if a VIEW is used in the WHERE clause (views essentially are sub-selects as well). >> Since SQL Server's ODBC driver supports SQL type binding, this >> is what mxODBC uses per default. >> >> cursor.executedirect() is a way to work around that default on >> a per-statement basis. It forces mxODBC to use Python type binding >> for that statement. > > But if I read the documentation correctly, doing this won't prepare the > statement, which will worsen the perfs if the statement is reused a lot. True, but with SQL Server it's usually better to run performance tests and then decide. More recent versions of SQL Server do some smart caching on the server side to avoid having to rerun the expensive prepare step. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 15 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 Apr 15 22:31:47 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Apr 15 21:31:04 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC746C6.5000004@egenix.com> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151714.02171.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> <4BC746C6.5000004@egenix.com> Message-ID: <4BC769A3.8010206@egenix.com> M.-A. Lemburg wrote: > Alexandre Fayolle wrote: >> Let me rephrase this. I was lazy, the call generating the exception was: >> >> datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) >> datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) >> cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, >> cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) >> >> The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL >> Server Native Client 10.0]Datetime field overflow. Fractional second precision >> exceeds the scale specified in the parameter binding.', 7748) > > This explains why you are seeing the error: Python datetime > instances use more than just 2 digits precision in their > seconds string representation, i.e. more than what SQL Server > expects when requesting timestamps as strings. > > However, I wonder why SQL Server requests this data as string > data, since it's well possible to use a native > timestamp ODBC data structure for this, which also assures > that full precision is maintained and no conversion takes place. > > Could you try the above with cursor.execute() and see whether > you still get the same error ? Normalizing the datetime values to not use microseconds should also solve the problem, even though that's not really satisfactory. Aside: SQL Server's DATETIME column type only has an accuracy of 0.00333 seconds: http://msdn.microsoft.com/en-us/library/ms186724.aspx -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 15 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 felciano at yahoo.com Thu Apr 15 15:39:07 2010 From: felciano at yahoo.com (Ramon Felciano) Date: Thu Apr 15 23:39:14 2010 Subject: [egenix-users] Parsing ARPA dates before Unix epoch breaks? Message-ID: Hi -- I've run into trouble parsing dates using the ARPA module in mxDateTime on Windows. It appears that it is based on a limitation around dates before the Unix epoch, which I thought this package helped you work around: >>> mx.__version__ '3.1.2' >>> mx.DateTime.ARPA.ParseDateTimeUTC("Thu, 1 Jan 1970 00:43:25 -0400").gmtoffset() >>> mx.DateTime.ARPA.ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400").gmtoffset() Traceback (most recent call last): File "", line 1, in Error: cannot convert value to a time value Is this expected behavior? Thanks, Ramon From mal at egenix.com Fri Apr 16 02:07:17 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Apr 16 01:06:34 2010 Subject: [egenix-users] Parsing ARPA dates before Unix epoch breaks? In-Reply-To: References: Message-ID: <4BC79C25.5060409@egenix.com> Ramon Felciano wrote: > Hi -- > > I've run into trouble parsing dates using the ARPA module in > mxDateTime on Windows. It appears that it is based on a limitation > around dates before the Unix epoch, which I thought this package > helped you work around: > >>>> mx.__version__ > '3.1.2' >>>> mx.DateTime.ARPA.ParseDateTimeUTC("Thu, 1 Jan 1970 00:43:25 -0400").gmtoffset() > >>>> mx.DateTime.ARPA.ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400").gmtoffset() > Traceback (most recent call last): > File "", line 1, in > Error: cannot convert value to a time value > > Is this expected behavior? Yes, since the .gmtoffset() method uses the C lib's time function in order to calculate the offset of the object's date/time to GMT/UTC, provided that the object uses local time. On some systems, this fails for dates prior to the epoch and there's nothing much we can do about it. On others it works just fine, e.g. Linux: >>> ParseDateTime("Wed, 1 Jan 1969 00:43:25").gmtoffset() >>> ParseDateTime("Wed, 1 Jan 1960 00:43:25").gmtoffset() >>> ParseDateTime("Wed, 1 Jan 1920 00:43:25").gmtoffset() >>> ParseDateTime("Wed, 1 Jan 1910 00:43:25").gmtoffset() >>> ParseDateTime("Wed, 1 Jan 1810 00:43:25").gmtoffset() >>> ParseDateTime("Wed, 1 Jan 1710 00:43:25").gmtoffset() Also note that ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400") will return a DateTime instance pointing to UTC time, ie. the .gmtoffset() is not applicable. You can use ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") to get the date/time parsed without the timezone part and then take the difference to extract the already provided timezone information: >>> from mx.DateTime.ARPA import * >>> offset = ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") - ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400") >>> offset -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 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 alexandre.fayolle at logilab.fr Fri Apr 16 09:46:33 2010 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Fri Apr 16 08:46:40 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <4BC746C6.5000004@egenix.com> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> <4BC746C6.5000004@egenix.com> Message-ID: <201004160846.34016.alexandre.fayolle@logilab.fr> On Thursday 15 April 2010 19:03:02 M.-A. Lemburg wrote: > Alexandre Fayolle wrote: > > Hello Charlie, > > > > Thanks for you answer. > > > > On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: > >> Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> > >> > >> > >> This looks like an incorrect application of the parameters. You *use* ? > >> for parameters in this case. You must use string formatting to generate > >> your SQL statement for "SELECT ?, ? FROM table" from your first example > >> because you are passing variables to a statement and not parameters to > >> the database which has already prepared the statement. > > > > Let me rephrase this. I was lazy, the call generating the exception was: > > > > datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) > > datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) > > cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, > > cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) > > > > The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL > > Server Native Client 10.0]Datetime field overflow. Fractional second > > precision exceeds the scale specified in the parameter binding.', 7748) > > This explains why you are seeing the error: Python datetime > instances use more than just 2 digits precision in their > seconds string representation, i.e. more than what SQL Server > expects when requesting timestamps as strings. > > However, I wonder why SQL Server requests this data as string > data, since it's well possible to use a native > timestamp ODBC data structure for this, which also assures > that full precision is maintained and no conversion takes place. > > Could you try the above with cursor.execute() and see whether > you still get the same error ? I've made some significant progress on this yesterday evening: * I've switched back from SQL Server Native Client 10 (the one for MS SQL 2008) to SQL Server Native Client (9?) (the one for MS SQL 2005), since the datetime precision issue was linked to the datetime2 datatype of SQL2008 : - http://msdn.microsoft.com/en-us/library/bb964722%28SQL.100%29.aspx - http://social.msdn.microsoft.com/Forums/en- US/sqldataaccess/thread/ac1b5a6d-5e64-4603-9c92-b75ba4e51bf2 I was using Native Client 10 because it solved some issues I had experiences with the previous driver + pyodbc. I don't have an SQL2008 db at hand to dig further into this, but maybe this is something you will want to investigate for your other users. * I've enclosed the cursor.execute statement in a try..except block which retries using cursor.executedirect if execute raised an exception * I"ve tweeked a bit our DB abstraction layer for additional differences between pyodbc and mxODBC (mainly related to datatype mapping) The only requests posing problems with cursor.execute in our application are * using ? in a SELECT list * using ? in a sub request with EXISTS So far, I've been able to avoid putting my hands in the SQL generator, but maybe I will need to do that. I'm currently running a test under the python profiler with mx and pyodbc to compare the run times, I'll send some figures here if I get interesting results. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From mal at egenix.com Fri Apr 16 11:32:34 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Apr 16 10:31:50 2010 Subject: [egenix-users] mx.ODBC error: Invalid Descriptor Index In-Reply-To: <201004160846.34016.alexandre.fayolle@logilab.fr> References: <201004131144.27619.alexandre.fayolle@logilab.fr> <201004151755.13360.alexandre.fayolle@logilab.fr> <4BC746C6.5000004@egenix.com> <201004160846.34016.alexandre.fayolle@logilab.fr> Message-ID: <4BC820A2.9020206@egenix.com> Alexandre Fayolle wrote: > On Thursday 15 April 2010 19:03:02 M.-A. Lemburg wrote: >> Alexandre Fayolle wrote: >>> Hello Charlie, >>> >>> Thanks for you answer. >>> >>> On Thursday 15 April 2010 17:30:06 Charlie Clark wrote: >>>> Am 15.04.2010, 17:14 Uhr, schrieb Alexandre Fayolle> >>>> >>>> >>>> This looks like an incorrect application of the parameters. You *use* ? >>>> for parameters in this case. You must use string formatting to generate >>>> your SQL statement for "SELECT ?, ? FROM table" from your first example >>>> because you are passing variables to a statement and not parameters to >>>> the database which has already prepared the statement. >>> >>> Let me rephrase this. I was lazy, the call generating the exception was: >>> >>> datetime1= datetime.datetime(2010, 4, 15, 16, 51, 25, 468000) >>> datetime2 = datetime.datetime(2010, 4, 15, 16, 51, 25, 453000) >>> cursor.executedirect('UPDATE cw_CWUser SET cw_modification_date = ?, >>> cw_last_login_time = ? WHERE cw_eid = ?', (datetime1, datetime2, 5)) >>> >>> The exception is mx.ODBC.Error.DataError: ('22008', 0, '[Microsoft][SQL >>> Server Native Client 10.0]Datetime field overflow. Fractional second >>> precision exceeds the scale specified in the parameter binding.', 7748) >> >> This explains why you are seeing the error: Python datetime >> instances use more than just 2 digits precision in their >> seconds string representation, i.e. more than what SQL Server >> expects when requesting timestamps as strings. >> >> However, I wonder why SQL Server requests this data as string >> data, since it's well possible to use a native >> timestamp ODBC data structure for this, which also assures >> that full precision is maintained and no conversion takes place. >> >> Could you try the above with cursor.execute() and see whether >> you still get the same error ? > > I've made some significant progress on this yesterday evening: > > * I've switched back from SQL Server Native Client 10 (the one for MS SQL > 2008) to SQL Server Native Client (9?) (the one for MS SQL 2005), since the > datetime precision issue was linked to the datetime2 datatype of SQL2008 : > > - http://msdn.microsoft.com/en-us/library/bb964722%28SQL.100%29.aspx > - http://social.msdn.microsoft.com/Forums/en- > US/sqldataaccess/thread/ac1b5a6d-5e64-4603-9c92-b75ba4e51bf2 > > I was using Native Client 10 because it solved some issues I had experiences > with the previous driver + pyodbc. I don't have an SQL2008 db at hand to dig > further into this, but maybe this is something you will want to investigate > for your other users. Thanks for those interesting links. This part appears to explain the problem: """ Stricter SQL_C_TYPE _TIMESTAMP and DBTYPE_DBTIMESTAMP parameter validation. Prior to SQL Server 2008 Native Client, datetime values were rounded to fit the scale of datetime and smalldatetime columns by SQL Server. SQL Server 2008 Native Client now applies the stricter validation rules that are defined in the ODBC core specification for fractional seconds. If a parameter value cannot be converted to the SQL type by using the scale specified or implied by the client binding without truncation of trailing digits, an error is returned. """ In other words, even if mxODBC uses the ODBC TIMESTAMP struct to pass the data to the driver, it will still complain if the second fraction value cannot be converted to the datetime accuracy without losing trailing digits. We will investigate this some more. The above driver behavior makes it somewhat difficult to send fractional seconds to the database without applying some kind of internal truncation in mxODBC in order to avoid the mentioned error. > * I've enclosed the cursor.execute statement in a try..except block which > retries using cursor.executedirect if execute raised an exception That's the same work-around that the new SQLAlchemy binding for mxODBC is using with SQL Server Native Client. > * I"ve tweeked a bit our DB abstraction layer for additional differences > between pyodbc and mxODBC (mainly related to datatype mapping) > > The only requests posing problems with cursor.execute in our application are > > * using ? in a SELECT list > * using ? in a sub request with EXISTS > > So far, I've been able to avoid putting my hands in the SQL generator, but > maybe I will need to do that. > > I'm currently running a test under the python profiler with mx and pyodbc to > compare the run times, I'll send some figures here if I get interesting > results. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 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 felciano at yahoo.com Fri Apr 16 16:20:51 2010 From: felciano at yahoo.com (Ramon Felciano) Date: Sat Apr 17 00:21:01 2010 Subject: [egenix-users] Parsing ARPA dates before Unix epoch breaks? In-Reply-To: References: <4BC79C25.5060409@egenix.com> Message-ID: (RESEND: Sorry, meant to CC the list on this as well...) Hi Marc -- Thanks for the quick reply. Is there a way I can re-construct the original date (with time offset) such that it will be formatted correctly by the mxTimeDate str() function? I'm not actually calling gmtoffset() myself, but that's where the str function seems to choke: >>> from mx.DateTime.ARPA import * >>> s = "Wed, 1 Jan 1969 00:43:25 -0400" >>> delta = ParseDateTime(s) - ParseDateTimeUTC(s) >>> delta >>> ParseDateTime(s) + delta >>> str(ParseDateTime(s) + delta) Traceback (most recent call last): ?File "", line 1, in ?File "C:\Python26\lib\site-packages\mx\DateTime\ARPA.py", line 170, in str ? ?tz = datetime.gmtoffset() Error: cannot convert value to a time value >>> Thanks, Ramon > On Thu, Apr 15, 2010 at 4:07 PM, M.-A. Lemburg wrote: >> Ramon Felciano wrote: >>> Hi -- >>> >>> I've run into trouble parsing dates using the ARPA module in >>> mxDateTime on Windows. It appears that it is based on a limitation >>> around dates before the Unix epoch, which I thought this package >>> helped you work around: >>> >>>>>> mx.__version__ >>> '3.1.2' >>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Thu, 1 Jan 1970 00:43:25 -0400").gmtoffset() >>> >>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400").gmtoffset() >>> Traceback (most recent call last): >>> ? File "", line 1, in >>> Error: cannot convert value to a time value >>> >>> Is this expected behavior? >> >> Yes, since the .gmtoffset() method uses the C lib's time function >> in order to calculate the offset of the object's date/time >> to GMT/UTC, provided that the object uses local time. >> >> On some systems, this fails for dates prior to the epoch and there's >> nothing much we can do about it. >> >> On others it works just fine, e.g. Linux: >> >>>>> ParseDateTime("Wed, 1 Jan 1969 00:43:25").gmtoffset() >> >>>>> ParseDateTime("Wed, 1 Jan 1960 00:43:25").gmtoffset() >> >>>>> ParseDateTime("Wed, 1 Jan 1920 00:43:25").gmtoffset() >> >>>>> ParseDateTime("Wed, 1 Jan 1910 00:43:25").gmtoffset() >> >>>>> ParseDateTime("Wed, 1 Jan 1810 00:43:25").gmtoffset() >> >>>>> ParseDateTime("Wed, 1 Jan 1710 00:43:25").gmtoffset() >> >> >> Also note that ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400") >> will return a DateTime instance pointing to UTC time, ie. the >> .gmtoffset() is not applicable. >> >> You can use ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") to >> get the date/time parsed without the timezone part and then >> take the difference to extract the already provided timezone >> information: >> >>>>> from mx.DateTime.ARPA import * >>>>> offset = ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") - ParseDateTimeUTC("Wed, 1 Jan 1969 >> 00:43:25 -0400") >>>>> offset >> >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Source ?(#1, Apr 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 felciano at yahoo.com Fri Apr 16 16:37:54 2010 From: felciano at yahoo.com (Ramon Felciano) Date: Sat Apr 17 00:38:00 2010 Subject: [egenix-users] Parsing ARPA dates before Unix epoch breaks? In-Reply-To: References: <4BC79C25.5060409@egenix.com> Message-ID: Never mind, I just noticed that the str() function has an optional timezone parameter, so the following seems to work: >>> s = "Wed, 1 Jan 1969 00:43:25 -0400" >>> delta = ParseDateTime(s) - ParseDateTimeUTC(s) Traceback (most recent call last): File "", line 1, in NameError: name 'ParseDateTime' is not defined >>> delta = mx.DateTime.ARPA.ParseDateTime(s) - mx.DateTime.ARPA.ParseDateTimeUTC(s) >>> mx.DateTime.ARPA.str(mx.DateTime.ARPA.ParseDateTime(s), delta) 'Wed, 01 Jan 1969 00:43:25 -0400' >>> Thanks! Ramon On Fri, Apr 16, 2010 at 3:20 PM, Ramon Felciano wrote: > (RESEND: Sorry, meant to CC the list on this as well...) > > Hi Marc -- > > Thanks for the quick reply. Is there a way I can re-construct the > original date (with time offset) such that it will be formatted > correctly by the mxTimeDate str() function? I'm not actually calling > gmtoffset() myself, but that's where the str function seems to choke: > >>>> from mx.DateTime.ARPA import * >>>> s = "Wed, 1 Jan 1969 00:43:25 -0400" >>>> delta = ParseDateTime(s) - ParseDateTimeUTC(s) >>>> delta > >>>> ParseDateTime(s) + delta > >>>> str(ParseDateTime(s) + delta) > Traceback (most recent call last): > ?File "", line 1, in > ?File "C:\Python26\lib\site-packages\mx\DateTime\ARPA.py", line 170, in str > ? ?tz = datetime.gmtoffset() > Error: cannot convert value to a time value >>>> > > Thanks, > > Ramon > >> On Thu, Apr 15, 2010 at 4:07 PM, M.-A. Lemburg wrote: >>> Ramon Felciano wrote: >>>> Hi -- >>>> >>>> I've run into trouble parsing dates using the ARPA module in >>>> mxDateTime on Windows. It appears that it is based on a limitation >>>> around dates before the Unix epoch, which I thought this package >>>> helped you work around: >>>> >>>>>>> mx.__version__ >>>> '3.1.2' >>>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Thu, 1 Jan 1970 00:43:25 -0400").gmtoffset() >>>> >>>>>>> mx.DateTime.ARPA.ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400").gmtoffset() >>>> Traceback (most recent call last): >>>> ? File "", line 1, in >>>> Error: cannot convert value to a time value >>>> >>>> Is this expected behavior? >>> >>> Yes, since the .gmtoffset() method uses the C lib's time function >>> in order to calculate the offset of the object's date/time >>> to GMT/UTC, provided that the object uses local time. >>> >>> On some systems, this fails for dates prior to the epoch and there's >>> nothing much we can do about it. >>> >>> On others it works just fine, e.g. Linux: >>> >>>>>> ParseDateTime("Wed, 1 Jan 1969 00:43:25").gmtoffset() >>> >>>>>> ParseDateTime("Wed, 1 Jan 1960 00:43:25").gmtoffset() >>> >>>>>> ParseDateTime("Wed, 1 Jan 1920 00:43:25").gmtoffset() >>> >>>>>> ParseDateTime("Wed, 1 Jan 1910 00:43:25").gmtoffset() >>> >>>>>> ParseDateTime("Wed, 1 Jan 1810 00:43:25").gmtoffset() >>> >>>>>> ParseDateTime("Wed, 1 Jan 1710 00:43:25").gmtoffset() >>> >>> >>> Also note that ParseDateTimeUTC("Wed, 1 Jan 1969 00:43:25 -0400") >>> will return a DateTime instance pointing to UTC time, ie. the >>> .gmtoffset() is not applicable. >>> >>> You can use ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") to >>> get the date/time parsed without the timezone part and then >>> take the difference to extract the already provided timezone >>> information: >>> >>>>>> from mx.DateTime.ARPA import * >>>>>> offset = ParseDateTime("Wed, 1 Jan 1969 00:43:25 -0400") - ParseDateTimeUTC("Wed, 1 Jan 1969 >>> 00:43:25 -0400") >>>>>> offset >>> >>> >>> -- >>> Marc-Andre Lemburg >>> eGenix.com >>> >>> Professional Python Services directly from the Source ?(#1, Apr 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 info at egenix.com Fri Apr 23 14:11:20 2010 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Fri Apr 23 13:13:04 2010 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 2.0.1 Message-ID: <4BD18058.6090606@egenix.com> ________________________________________________________________________ ANNOUNCEMENT mxODBC Zope Database Adapter Version 2.0.1 for Zope and the Plone CMS Available for Zope 2.12 and later on Windows, Linux, Mac OS X, FreeBSD and other platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Zope-DA-2.0.1-GA.html ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter allows you to easily connect your Zope or Plone installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. The mxODBC Zope Database Adapter is highly portable, just like Zope itself and provides a high performance interface to all your ODBC data sources, using a single well-supported interface on Windows, Linux, Mac OS X, FreeBSD and other platforms. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority, establishing an excellent basis and scalable solution for your Plone CMS. ________________________________________________________________________ NEWS We are pleased to announce a new version 2.0.1 of our mxODBC Zope DA product. With the patch level 2.0.1 release we have backported the mxODBC Zope DA product to also run on Zope 2.10, 2.11 as well as Python 2.4. This was done to meet popular demand, since Plone 3 still uses these Zope and Python versions. The mxODBC Zope DA is now fully compatible with all recent Plone versions, including the upcoming Plone 4.0 release. Please see the mxODBC Zope DA documentation for details on how to install the product for use in Plone. Compared to the previous 1.0 version of the mxODBC Zope DA, the 2.0 version includes these enhancements: * Includes mxODBC 3.1 with updated support for many current ODBC drivers, giving you more portability and features for a wider range of database backends. * Mac OS X 10.6 (Snow Leopard) support. * Python 2.4, 2.5 and 2.6 support. * Zope 2.10, 2.11 and 2.12 support. * Zero maintenance support to automatically reconnect the Zope connection after a network or database problem. * More flexible Unicode support with options to work with pure Unicode, plain strings or mixed setups - even for databases that don't support Unicode * Automatic and transparent text encoding and decoding * More flexible date/time support including options to work with Python datetime objects, mxDateTime, strings or tuples * New decimal support to have the Zope DA return decimal column values using Python's decimal objects. * Fully eggified to simplify easy_install and zc.buildout based installation ________________________________________________________________________ UPGRADING Licenses purchased for version 2.0.0 of the mxODBC Zope DA will continue to work with the 2.0.1 patch level release. If you have already bought mxODBC Zope DA 1.0.x licenses, we offer you a time limited upgrade option: * If you have purchased the licenses between 2009-06-01 and 2009-12-31 you can get a 20% discount on the full price of version 2.0. * If you have purchased the licenses after 2010-01-01 you can get a 40% discount on the full price of version 2.0. This offer is time limited until 2010-09-30. Please write to sales@egenix.com for details on how to get the needed discount coupons. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope Database Adapter, licensing and download instructions, please visit our web-site: http://www.egenix.com/products/zope/mxODBCZopeDA/ 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, Apr 23 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 Fri Apr 23 16:59:14 2010 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Apr 23 15:59:17 2010 Subject: [egenix-users] eGenix PyPI-like package index available Message-ID: <4BD1A7B2.1080001@egenix.com> Hello eGenix Users, in the past few months we've experimented with our own PyPI-style egg package index. This was needed since we wanted to provide downloadable egg files, but needed to ship both UCS2 and UCS4 builds of the eggs. Since setuptools and easy_install don't differentiate between those two Python build versions, we couldn't use PyPI itself for hosting the files and decided to build a simple, but effective index ourselves. Index ----- Here's the URL for the UCS2 index, which you can use for Windows eggs as well as self compiled Python versions on Unix: http://downloads.egenix.com/python/index/ucs2/ and this is the one for UCS4 builds, which are commonly used for eggs needed by Linux-distribution Python versions: http://downloads.egenix.com/python/index/ucs4/ Usage ----- Usage is easy, e.g. easy_install \ -i http://downloads.egenix.com/python/index/ucs2/ \ egenix-mx-base will install the latest egenix-mx-base distribution. If you want to install a specific version, you can also point easy_install to the version directory: easy_install \ -i http://downloads.egenix.com/python/index/ucs2/egenix-mx-base/3.1.3/ \ egenix-mx-base or you use the version selection mechanism from setuptools for this: easy_install \ -i http://downloads.egenix.com/python/index/ucs2/ \ "egenix-mx-base == 3.1.3" Buildout -------- The same can be done from zc.buildout. You only need to add the index URL to the "find-links" entry of the [buildout] section and the corresponding package name to the "eggs" entry. To pin down specific versions of a package, you can add a "versions=versions" entry to the [buildout] section and a new section """ [versions] egenix-mx-base == 3.1.3 """ to the buildout.cfg file. Quirks ------ The easy_install method only works reliably on Linux and Windows, due to the way it searches for the right egg files. On Macs and FreeBSD, the platform string is not unified, so easy_install will likely not find the right egg for your platform. In such a case, you will have to download the egg archive and then point easy_install directly to the egg file. For buildout, you will have to rename the file to whatever platform string easy_install uses to search for the right egg. Plans ----- We currently have the egenix-mx-base packages and egenix-mxodbc-zopeda up on the index, but will extend this to more packages as we release new versions. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 23 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 rshea at thecubagroup.com Sun Apr 25 01:28:31 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sat Apr 24 14:28:36 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? Message-ID: <1272112111.27218.1371676227@webmail.messagingengine.com> Hi - I've installed mxODBC Zope DA into a Plone 3.3 instance. I believe I've configured the odbc.ini correctly. The mxODBC installation instructions say that at startup messages will be seen ... [quote] At Zope startup time, the Zope DA tries to import the interfaces for the two ODBC managers and writes a notice to the Zope startup shell window. Zope can only use those interfaces which are successfully imported at this point. If both interfaces fail to load, the mxODBC Zope DA will not be usable at all and a warning message is printed to the startup shell. [/quote] .... I'm not getting any sort of message at all - neither confirmation nor warning ! The doco also says that messages will be written to /log/events.log but that file is not being created . If anyone can explain why I'm not getting any sort of notification I would be grateful . thanks Richard. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From charlie at egenix.com Sat Apr 24 15:31:00 2010 From: charlie at egenix.com (Charlie Clark) Date: Sat Apr 24 14:31:05 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: <1272112111.27218.1371676227@webmail.messagingengine.com> References: <1272112111.27218.1371676227@webmail.messagingengine.com> Message-ID: Am 24.04.2010, 14:28 Uhr, schrieb Richard Shea : > Hi - I've installed mxODBC Zope DA into a Plone 3.3 instance. I believe > I've configured the odbc.ini correctly. > The mxODBC installation instructions say that at startup messages will > be seen ... Hi Richard, can you let us know what version of the Zope DA you're using? Are you testing checking by running the bin/instance fg from the shell? 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 rshea at thecubagroup.com Sun Apr 25 01:41:37 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sat Apr 24 14:41:43 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: References: <1272112111.27218.1371676227@webmail.messagingengine.com> Message-ID: <1272112897.28734.1371677449@webmail.messagingengine.com> Thanks for speedy reply. The version I'm running is 2.0. > testing checking by running the bin/instance fg from the shell? I'm not a Zope guru - that bit was all new to me. I have however now got a prompt ... zopectl> ... what would be useful to enter at the prompt to analyse this problem ? thanks Richard. On Sat, 24 Apr 2010 14:31 +0200, "Charlie Clark" wrote: > Am 24.04.2010, 14:28 Uhr, schrieb Richard Shea : > > > Hi - I've installed mxODBC Zope DA into a Plone 3.3 instance. I believe > > I've configured the odbc.ini correctly. > > The mxODBC installation instructions say that at startup messages will > > be seen ... > > Hi Richard, > > can you let us know what version of the Zope DA you're using? Are you > testing checking by running the bin/instance fg from the shell? > > 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/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From rshea at thecubagroup.com Sun Apr 25 01:42:23 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sat Apr 24 14:42:27 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: References: <1272112111.27218.1371676227@webmail.messagingengine.com> Message-ID: <1272112943.29106.1371678039@webmail.messagingengine.com> Sorry just re-read. I'm trying fg now. On Sat, 24 Apr 2010 14:31 +0200, "Charlie Clark" wrote: > Am 24.04.2010, 14:28 Uhr, schrieb Richard Shea : > > > Hi - I've installed mxODBC Zope DA into a Plone 3.3 instance. I believe > > I've configured the odbc.ini correctly. > > The mxODBC installation instructions say that at startup messages will > > be seen ... > > Hi Richard, > > can you let us know what version of the Zope DA you're using? Are you > testing checking by running the bin/instance fg from the shell? > > 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/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From rshea at thecubagroup.com Sun Apr 25 01:47:02 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sat Apr 24 14:47:07 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: References: <1272112111.27218.1371676227@webmail.messagingengine.com> Message-ID: <1272113222.29766.1371678293@webmail.messagingengine.com> OK well when I run fg at the zopectl prompt I get ... 2010-04-25 00:41:56 INFO ZServer HTTP server started at Sun Apr 25 00:41:56 2010 Hostname: 0.0.0.0 Port: 8080 2010-04-25 00:41:58 INFO Marshall libxml2-python not available. Unable to register libxml2 based marshallers, at least SimpleXMLMarshaller make_top_level_package: Importing embedded mx package Products.mxODBCZopeDA.mx make_top_level_package: No pre-existing mx top-level package found. make_top_level_package: Installing embedded mx package as top-level package. 2010-04-25 00:42:00 INFO root eGenix mxODBC Zope DA: Using mx.ODBC.iODBC 3.1.0 package as default interface 2010-04-25 00:42:00 INFO root eGenix mxODBC Zope DA: License: EVALUATION USE Zope Instance License for Richard Shea, T h e C u b a Group [127210062025#1] 2010-04-25 00:42:01 INFO Plone Dependency Unable to detect Zope version. Please make sure you have Zope 2.10.4 or newer installed. 2010-04-25 00:42:07 INFO Zope Ready to handle requests .. apart from the inability to detect the Zope version that all seems to look reasonable to me - would you agree ? thanks R. On Sat, 24 Apr 2010 14:31 +0200, "Charlie Clark" wrote: > Am 24.04.2010, 14:28 Uhr, schrieb Richard Shea : > > > Hi - I've installed mxODBC Zope DA into a Plone 3.3 instance. I believe > > I've configured the odbc.ini correctly. > > The mxODBC installation instructions say that at startup messages will > > be seen ... > > Hi Richard, > > can you let us know what version of the Zope DA you're using? Are you > testing checking by running the bin/instance fg from the shell? > > 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/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From charlie at egenix.com Sat Apr 24 16:51:08 2010 From: charlie at egenix.com (Charlie Clark) Date: Sat Apr 24 15:51:13 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: <1272113222.29766.1371678293@webmail.messagingengine.com> References: <1272112111.27218.1371676227@webmail.messagingengine.com> <1272113222.29766.1371678293@webmail.messagingengine.com> Message-ID: Am 24.04.2010, 14:47 Uhr, schrieb Richard Shea : > 2010-04-25 00:42:00 INFO root eGenix mxODBC Zope DA: License: EVALUATION > USE Zope Instance License for Richard Shea, T h e C u b a Group h e c u b a g r o u p.com> [127210062025#1] > 2010-04-25 00:42:01 INFO Plone Dependency > Unable to detect Zope version. Please make sure you have Zope 2.10.4 or > newer installed. > 2010-04-25 00:42:07 INFO Zope Ready to handle requests > .. apart from the inability to detect the Zope version that all seems to > look reasonable to me - would you agree ? Yes, that looks correct. You should be able to see the mxODBC Zope DA in the Products section of your site from the Zope Management http://localhost:8080/manage If this is the case you can add a connection object anywhere in your site and access any configured DSNs. NB. your zope user must be able to see the DSNs. 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 rshea at thecubagroup.com Sun Apr 25 18:10:47 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sun Apr 25 07:10:55 2010 Subject: [egenix-users] mxODBC Zope DA - no message at startup / no log ? In-Reply-To: References: <1272112111.27218.1371676227@webmail.messagingengine.com><1272113222.29766.1371678293@webmail.messagingengine.com> Message-ID: <1272172247.18352.1371750989@webmail.messagingengine.com> Hi Charlie - Thanks very much for your help. I am able to see the DA as you described and have been able to a connection member. Very grateful to you for your help. Regards Richard. On Sat, 24 Apr 2010 15:51 +0200, "Charlie Clark" wrote: > Am 24.04.2010, 14:47 Uhr, schrieb Richard Shea : > > > 2010-04-25 00:42:00 INFO root eGenix mxODBC Zope DA: License: EVALUATION > > USE Zope Instance License for Richard Shea, T h e C u b a Group > h e c u b a g r o u p.com> [127210062025#1] > > 2010-04-25 00:42:01 INFO Plone Dependency > > Unable to detect Zope version. Please make sure you have Zope 2.10.4 or > > newer installed. > > 2010-04-25 00:42:07 INFO Zope Ready to handle requests > > .. apart from the inability to detect the Zope version that all seems to > > look reasonable to me - would you agree ? > > Yes, that looks correct. You should be able to see the mxODBC Zope DA in > the Products section of your site from the Zope Management > http://localhost:8080/manage > > If this is the case you can add a connection object anywhere in your site > and access any configured DSNs. NB. your zope user must be able to see > the > DSNs. > > 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/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From rshea at thecubagroup.com Sun Apr 25 22:34:02 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sun Apr 25 11:34:07 2010 Subject: [egenix-users] mxODBC Zope DA - simple example ? Message-ID: <1272188042.22823.1371764081@webmail.messagingengine.com> Hi - More questions ! I have installed mxODBC Zope DA and I have found the .zexp at http://www.egenix.com/library/presentations/EuroPython2007-Zope-and-RDBMS/ and have imported it within my plone instance. I created a new plone folder, foo, and imported the .zexp within foo. In ZMI a folder ACME is now visible within foo. However ACME is not seen as content within foo when viewed via Plone. What I want initially is just to demonstrate a table being dumped to the screen. Within ACME the script ACME/admin/event script looks like an ideal example. Can anyone tell me what I would need to do to invoke it ? Thanks richard. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From charlie at egenix.com Sun Apr 25 13:07:22 2010 From: charlie at egenix.com (Charlie Clark) Date: Sun Apr 25 12:07:24 2010 Subject: [egenix-users] mxODBC Zope DA - simple example ? In-Reply-To: <1272188042.22823.1371764081@webmail.messagingengine.com> References: <1272188042.22823.1371764081@webmail.messagingengine.com> Message-ID: Am 25.04.2010, 11:34 Uhr, schrieb Richard Shea : > Hi - More questions ! I have installed mxODBC Zope DA and I have found > the .zexp at > http://www.egenix.com/library/presentations/EuroPython2007-Zope-and-RDBMS/ > and have imported it within my plone instance. > I created a new plone folder, foo, and imported the .zexp within foo. In > ZMI a folder ACME is now visible within foo. However ACME is not seen as > content within foo when viewed via Plone. > What I want initially is just to demonstrate a table being dumped to the > screen. Within ACME the script ACME/admin/event script looks like an > ideal example. > Can anyone tell me what I would need to do to invoke it ? Hiya Richard, nice to see someone trying out my sample code! The problem is that Plone expects "specific content objects" to work with. That example was designed to work in any Zope instance so you will be able to see it if you call it directly via URL, ie. http://localhost:8080/Plone/ACME. But you might be better off installing ACME in the root Zope folder next to Plone. This will let you get familiar with how Zope integrates with external data sources. Pretty much everything in ACME can be done in Plone but things are slightly different - you add an ACME "skin" to Plone and put the contents of ACME in there. Hope that helps! Things have moved on in the Zope world since 2007 so it might be time for us to update this tutorial. 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 rshea at thecubagroup.com Mon Apr 26 00:48:46 2010 From: rshea at thecubagroup.com (Richard Shea) Date: Sun Apr 25 13:48:52 2010 Subject: [egenix-users] mxODBC Zope DA - simple example ? In-Reply-To: References: <1272188042.22823.1371764081@webmail.messagingengine.com> Message-ID: <1272196126.10514.1371773905@webmail.messagingengine.com> That's great thanks. Having imported ACME into the root Zope folder I'm now getting a response when I request ... http://myserver:8080/Plone/ACME/admin ... and also when I request ... http://myserver:8080/Plone/ACME/training It's actually blowing up in response to that second request but that (I'm reasonably certain) is only down to my not yet having installed the database. Bit late here to do that now - will try tomorrow. thanks again for your help. Richard. On Sun, 25 Apr 2010 12:07 +0200, "Charlie Clark" wrote: > Am 25.04.2010, 11:34 Uhr, schrieb Richard Shea : > > > Hi - More questions ! I have installed mxODBC Zope DA and I have found > > the .zexp at > > http://www.egenix.com/library/presentations/EuroPython2007-Zope-and-RDBMS/ > > and have imported it within my plone instance. > > I created a new plone folder, foo, and imported the .zexp within foo. In > > ZMI a folder ACME is now visible within foo. However ACME is not seen as > > content within foo when viewed via Plone. > > What I want initially is just to demonstrate a table being dumped to the > > screen. Within ACME the script ACME/admin/event script looks like an > > ideal example. > > Can anyone tell me what I would need to do to invoke it ? > > Hiya Richard, > > nice to see someone trying out my sample code! > > The problem is that Plone expects "specific content objects" to work > with. > That example was designed to work in any Zope instance so you will be > able > to see it if you call it directly via URL, ie. > http://localhost:8080/Plone/ACME. > > But you might be better off installing ACME in the root Zope folder next > to Plone. This will let you get familiar with how Zope integrates with > external data sources. Pretty much everything in ACME can be done in > Plone > but things are slightly different - you add an ACME "skin" to Plone and > put the contents of ACME in there. > > Hope that helps! Things have moved on in the Zope world since 2007 so it > might be time for us to update this tutorial. > > 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/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Cuba Group PO Box 15041 Wellington New Zealand PH +64 4 496 5205 MO +64 21 976 683 FX +64 4 496 5209 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++